Cloudified mac scheduler

ABSTRACT

Some embodiments provide a method for performing radio access network (RAN) functions in a cloud at a medium access control (MAC) scheduler application that executes on a machine deployed on a host computer in the cloud. The method receives data, via a RAN intelligent controller (RIC), from a first RAN component. The method uses the received data to generate a MAC scheduling output. The method provides the MAC scheduling output to a second RAN component via the RIC.

CLAIM OF BENEFIT TO PRIOR APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication 63/157,351, filed Mar. 5, 2021; U.S. Provisional PatentApplication 63/157,600, filed Mar. 5, 2021; U.S. Provisional PatentApplication 63/176,859, filed Apr. 19, 2021; and U.S. Provisional PatentApplication 63/180,627, filed Apr. 27, 2021. U.S. Provisional PatentApplications 63/157,351, 63/157,600, 63/176,859, and 63/180,627 areincorporated herein by reference.

BACKGROUND

In telecommunications networks, the Radio Access Network (RAN) performsmore and more functions with each iteration of the telecommunicationsstandards. That is, in order to enable the advantages of 5G overprevious standards, the 5G RAN performs various additional functions.These RAN functions are situated between user devices and the corenetwork and are thus often performed at the base stations (e.g., celltowers) where computing power can be limited.

BRIEF SUMMARY

Some embodiments provide a method for offloading medium access control(MAC) scheduler and/or user-level tracing operations in an Open RadioAccess (O-RAN) network to a set of applications that execute on machinesdeployed on a host computer in a cloud (e.g., a software-defineddatacenter). These applications receive data from O-RAN components(e.g., Distributed Unit (O-DU) and/or Centralized Unit (O-CU)components) via a distributed near real-time RAN intelligent controller(RIC) and use the received data to perform their respective operations.For instance, the MAC scheduler application(s) generate MAC schedulingoutput (e.g., related to at least one 5G user) while the user-leveltracing application(s) generate information related to trafficperformance for at least one 5G user. In some embodiments, the MACscheduler application(s) provide the generated MAC scheduling outputback to the RAN via the RIC, while the user-level tracing application(s)provide data to the RIC (e.g., for use by another application, includingthe MAC scheduler application(s)).

In some embodiments, to enable the interaction of the applications withthe RIC, machines (e.g., VMs, containers, etc.) are deployed on a hostcomputer. On each machine, a control plane application (e.g., the MACscheduler applications, user level tracing applications, other controlplane applications) is deployed. In addition, a RIC software developmentkit (SDK) is configured on each of the machines to serve as an interfacebetween the control plane application on the same machine and the RAN.The RIC SDK provides a set of connectivity APIs (e.g., a framework)through which applications (e.g., the control plane applications) cancommunicate with the distributed near real-time (RT) RIC. In someembodiments, the RIC framework on each machine includes a set of networkconnectivity processes that establish network connections to the set ofE2 nodes for the control plane application.

In addition to communicating with the DU and/or CU (also referred to asE2 nodes in reference to the E2 interface between these components andthe RIC) via the RIC framework, in some embodiments the control planeapplications connect with network elements of the MC. These networkelements may include at least one shared data layer (SDL) element insome embodiments that provides access to a shared SDL storage of the MC.Some embodiments deploy an SDL cache on the same host computer as acontrol plane application (e.g., on the same machine or on the hostcomputer outside of the machine on which the control plane applicationis deployed) and use this cache to process at least a subset of the SDLstorage access requests of the control plane application. In someembodiments, multiple control plane applications executing on the samehost computer use a common SDL cache on that host computer. In someembodiments, the data stored in the SDL cache is synchronized with datastored in the SDL storage (e.g., a database). When the RIC framework isunable to process SDL access requests through the SDL cache, the RIC orthe RIC framework forwards the SDL access requests to the SDL storage.

Through the RIC, the RIC framework also connects the control planeapplication to other control plane applications executing on othermachines in some embodiments (deployed on different host computers or onthe same host computer). For instance, some embodiments deploy severalRICs to execute on several host computers to implement a distributed RICthat serves as a communication interface between the control planeapplications.

To receive data from the E2 nodes, in some embodiments an applicationsubscribes to a specific type of data with an E2 node, via the RIC. Theapplication sends a subscription request to the RIC (e.g., via the setof connectivity APIs), which records the request and generates asubscription request to send via the E2 interface. The RIC sends thissubscription request to the correct E2 node (or set of E2 nodes, if theinformation should be received from numerous E2 nodes, such as a set ofDUs at different base stations) and stores subscription forwardinginformation. When the E2 nodes send a subscription acknowledgement backto the RIC, the RIC uses the subscription forwarding information toprovide confirmation to the correct application.

The stored subscription forwarding information is also used by the RICto route runtime data received from the E2 nodes based on thesubscriptions to the correct application(s) and to route output data(e.g., generated by the MAC scheduler applications) to the correct E2nodes. When one or more applications are subscribed to a particular typeof data with an E2 node, that node sends the data to the RIC (e.g., asthe data becomes available). The RIC uses the subscription forwardinginformation to route the data to any applications subscribing to thedata.

The output data from the MAC scheduler and user-level tracingapplications may be sent back to an E2 node (e.g., either the same E2node from which the application received data or a different E2 node) orto another application. For instance, many MAC scheduler applicationsperform functions previously handled by the DU, taking advantage of thegreater processing power available in cloud datacenters as compared to awireless base station. In this case, the MAC scheduler applicationgenerates its output based on data received from the DU and sends theoutput back to the RIC. The MC uses stored forwarding information tocorrectly forward the output data to the DU for the DU to use to performRAN functions (e.g., beamforming for mobile devices connected to thebase station).

When one application (e.g., a user-level tracing application) sends itsoutput data to another application, this communication occurs throughthe RIC framework in some embodiments. If the first application sendsits output data to the other application directly, in some embodiments amessaging infrastructure of the RIC framework handles thiscommunication. In other cases, however, the output data is stored intothe SDL storage by the first application. This allows the otherapplication to retrieve the data via the SDL on an as-needed basis.

Different examples of MAC scheduler applications include a UE-specificbeamforming weight application, a UE radio frequency (RF) conditionprediction application, and a multi-user multi-input multi-output(MU-MIMO) pairing suggestion application. Each of these applicationsreceives specific types of data from the DU (via the E2 interface andthe RIC framework) and provides its output data to the DU. Theseapplications may also receive other information (e.g., to perform morecomplex operations than would be available at the DU) from other sources(e.g., other applications, such as the user-level tracing applications).

For the UE-specific beamforming weight application, in some embodimentsthe DU exposes a report interface by which to provide an uplink SoundingReference Signal (UL SRS) channel response matrix that is an input tothe weight calculation function performed by this application. Thebeamforming weight application computes a UE-specific beamformingmatrix, which is provided to the DU via an exposed control interface.

For the UE RF condition prediction application, in some embodiments theDU exposes a report interface by which to provide a downlink (DL)channel condition report that is an input to the RF condition predictionfunction performed by this application. The UE RF condition predictionapplication computes a predicted DL channel condition (e.g., includingDL signal to interference and noise ratio (SINR), precoder matrixindicator (PMI), and rank) for the next scheduling window, which isprovided to the DU via an exposed control interface.

For the MU-MIMO pairing suggestion application, in some embodiments theDU exposes a report interface by which to provide UE-specificbeamforming matrices that are inputs to the pairing suggestion functionperformed by this application. The MU-MIMO pairing suggestionapplication computes a UE pairing suggestion and SINR impact assessment,which are provided to the DU via an exposed control interface.

The user-level tracing applications of some embodiments generateinformation related to traffic performance and/or user configuration forat least one user. This tracing data can be used as inputs to variouscontrol plane algorithms at other applications and/or the E2 nodes,including some or all of the MAC scheduler operations, parameter settingapplications, etc. These tracing applications can (i) track userbehavior in a cell, (ii) track user RF condition, (iii) track user datatraffic performance in different layers (MAC, Radio Link Control (RLC),Packet Data Convergence Protocol (PDCP)), and/or (iv) track user RFresource consumption.

For the user-level tracing applications, in some embodiments the DUexposes report interfaces to provide various metrics to the user-leveltracing operations. These metrics can include selected Radio ResourceControl (RRC) messages, MAC/RLC/PDCP traffic volume and performance, RFcondition, and RF resource consumption. In some embodiments, messagesover these interfaces to the RIC are triggered based on user behaviorand/or periodic reporting. The tracing operations track the various userdata indicated above and can provide this information either back to theE2 nodes or to other control applications operating at the RIC (e.g.,the MAC scheduler applications). For instance, these applications mightperform analysis on the user data performance received from theuser-level tracing applications, determine that certain performance isinadequate, and modify how the RAN is treating the user traffic.

The preceding Summary is intended to serve as a brief introduction tosome embodiments of the invention. It is not meant to be an introductionor overview of all inventive subject matter disclosed in this document.The Detailed Description that follows and the Drawings that are referredto in the Detailed Description will further describe the embodimentsdescribed in the Summary as well as other embodiments. Accordingly, tounderstand all the embodiments described by this document, a full reviewof the Summary, Detailed Description, and the Drawings is needed.Moreover, the claimed subject matters are not to be limited by theillustrative details in the Summary, Detailed Description, and theDrawings, but rather are to be defined by the appended claims, becausethe claimed subject matters can be embodied in other specific formswithout departing from the spirit of the subject matters.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth in the appendedclaims. However, for purpose of explanation, several embodiments of theinvention are set forth in the following figures.

FIG. 1 illustrates an example of O-RAN architecture according to someembodiments.

FIG. 2 illustrates an in-depth view of the components of both anon-real-time RIC and a near real-time RIC according to someembodiments.

FIG. 3 illustrates another view of the O-RAN architecture of someembodiments, with a more in-depth view of the near real-time RIC.

FIG. 4 illustrates deployment of RIC SDKs on machines that executecontrol plane applications in some embodiments.

FIG. 5 illustrates that some embodiments deploy several RICs to executeon several host computers to implement a distributed near-RT RIC thatincludes the RIC components illustrated in FIGS. 3 and 4 .

FIG. 6 illustrates a RIC that executes on one host computer along withtwo machines on which two control plane applications execute.

FIG. 7 illustrates two RICs that execute on two host computers alongwith two machines on which two control plane applications and two RICSDKs execute.

FIG. 8 illustrates a RIC that executes on a first host computer toconnect two control plane applications that execute on two machinesoperating on two other host computers.

FIG. 9 illustrates a RIC that executes on a first host computer toconnect two control plane applications that execute on two machines, oneof which operates on the first host computer while the other operates onanother host computer.

FIG. 10 illustrates examples of the different standard specified APIsthat the distributed near-RT RIC platform of some embodiments supports.

FIG. 11 illustrates embodiments in which the SDL cache is part of eachMC SDK that executes on the same machine as its control planeapplication.

FIG. 12 illustrates an example of control or edge applications that havepassthrough access to hardware accelerator of their host computer toperform some or all of their computations.

FIG. 13 illustrates a process that is performed in some embodiments inresponse to an O-RAN component directing a CP or edge application toperform an operation that requires the application to use a hardwareaccelerator of its host computer.

FIG. 14 illustrates an application performing an operation based on datafrom an E2 node.

FIG. 15 illustrates another example of a control or edge applicationsthat have passthrough access to a hardware accelerator of their hostcomputer to perform some (or all) of their computations.

FIG. 16 illustrates yet another example of CP or edge applications thathas passthrough access to a hardware accelerator of their host computerto perform some or all of their computations.

FIG. 17 illustrates a process that some embodiments use to deploy O-RANapplications with direct, passthrough access to the hardwareaccelerators of their host computers.

FIG. 18 illustrates an example of CP or edge applications that havepassthrough access to virtual hardware accelerator defined by ahypervisor executing on their host computer.

FIG. 19 illustrates data flow for a set of MAC scheduler applicationsthat operate on top of the distributed near real-time RIC.

FIG. 20 conceptually illustrates a process of some embodiments for thedistributed near real-time RIC to provide subscription data from an E2node to applications.

FIG. 21 conceptually illustrates a process of some embodiments for thedistributed near real-time RIC to provide data output by an applicationto one or more E2 nodes.

FIG. 22 illustrates data flow for a user-level tracing application aswell as other applications that operate on top of the distributed nearreal-time RIC.

FIG. 23 conceptually illustrates an electronic system with which someembodiments of the invention are implemented.

DETAILED DESCRIPTION

In the following detailed description of the invention, numerousdetails, examples, and embodiments of the invention are set forth anddescribed. However, it will be clear and apparent to one skilled in theart that the invention is not limited to the embodiments set forth andthat the invention may be practiced without some of the specific detailsand examples discussed.

Today, there is a push to have RAN implemented as O-RAN, a standard forallowing interoperability for RAN elements and interfaces. FIG. 1illustrates an example of O-RAN architecture 100, according to someembodiments. The O-RAN architecture 100 includes a service managementand orchestration framework (SMO) 110 with a non-real-time RIC 105, anear real-time RAN intelligent controller (RIC) 115, an open centralunit control plane (O-CU-CP) 120, an open central unit user plane(O-CU-UP) 125, open distributed unit (O-DU) 130, an open radio unit(O-RU) 135, and an O-Cloud 140. The O-CU-CP 120, the O-CU-UP 125, andthe O-DU 130 may be collectively referred to as the managed functions120-130 below.

As defined in the standard, the SMO 110 in some embodiments includes anintegration fabric that allows the SMO to connect to and manage the RIC115, the managed functions 120-130, and the O-Cloud 140 via the openinterfaces 150. Unlike these elements, the O-RU 135 is not managed bythe SMO 110, and is instead managed by the O-DU 130, as indicated by thedashed line 160, in some embodiments. In some embodiments, the O-RU 135processes and sends radio frequencies to the O-DU 130.

In some embodiments, the managed functions 120-130 are logical nodesthat each host a set of protocols. According to the O-RAN standard, forexample, the O-CU-CP 120, in some embodiments, include protocols such asradio resource control (RRC) and the control plane portion of packetdata convergence protocol (PDCP), while the O-CU-UP 125 includesprotocols such as service data adaptation protocol (SDAP), and the userplane portion of PDCP.

The two RICs are each adapted to specific control loop and latencyrequirements. The near real-time RIC (near-RT RIC) 115 providesprogrammatic control of open centralized units (O-CUs) and opendistributed units (O-DUs) on time cycles of 10 ms to 1 second. Thenon-real-time RIC (non-RT RIC) 105, on the other hand, provides higherlayer policies that can be implemented in the RAN either via the near-RTMC 115 or via a direct connection to RAN nodes. The non-RT MC is usedfor control loops of more than 1 second. Each MC 105 or 115 serves as aplatform on which RAN control applications execute. These applicationscan be developed by third-party suppliers that are different from theRIC vendors. These applications are referred to as “xApps” (for thenear-RT RIC 115) and “rApps” (for the non-RT RIC 105).

The near real-time RIC 115, in some embodiments, is a logicalaggregation of several functions that use data collection andcommunications over the interfaces 155 in order to control the managedfunctions 120-130. In some embodiments, the non-real-time RIC 105 usesmachine learning and model training in order to manage and optimize themanaged functions 120-130. The near-RT RIC 115 in some of theseembodiments also uses machine learning.

In some embodiments, the O-Cloud 140 is responsible for creating andhosting virtual network functions (VNFs) for use by the near-RT RIC 115and the managed functions 120-130. In some embodiments, the DU is incharge of per-slot decisions of user scheduling and includes a RANscheduler that performs MAC control assistance and user-level tracing.In order to increase computing power available in the cloud (i.e.,compared to base stations that typically execute the RAN functions), theRIC is implemented in one or more public and/or private clouddatacenters and implements MAC scheduling and user-level tracing,thereby offloading these functions from the DU to the RIC. Theinterfaces 155 in some embodiments enable the RAN to provide inputs tothe functions at the RIC, and, at least in some embodiments, receiveoutputs that have been computed by these functions at the RIC.

FIG. 2 illustrates an in-depth view of the components of both anon-real-time RIC 201 and a near real-time RIC 202. Each of the RICs 201and 202 includes a respective set of analytics functions 210 and 212,and a respective set of optimization functions 214 and 216, which areeach illustrated with dashed lines to indicate they are existingcomponents. In addition to these existing components, the near real-timeoptimization functions 216 includes two new components, the MAC controlassistor 220 and user-level tracer 222, illustrated with solid lines tovisually differentiate them from the existing components. In someembodiments, these components are part of a larger MIMO component (e.g.,along with the MU-MIMO UE pairer and precoder).

In some embodiments, the MAC control assistor 220 can include variousfunctions such as (1) User Equipment (UE)-specific beamforming weightcalculation based on UL SRS channel signal reception, (2) UE RadioFrequency (RF) condition prediction, and (3) Multi-User, Multiple Input,Multiple Output (MU-MIMO) pairing suggestion for the MAC scheduler basedon the UE-specific beams. For each of these functions, some embodimentsexpose a report interface (that provides input data for the function tothe RIC from the DU) and a control interface (that provides output datafor the function to the DU from the RIC).

The user-level tracer 222, in some embodiments, produces L1/L2/L3 levelinformation related to user configuration and traffic performance. Thistracing data can be used as inputs to various control algorithms,including the MAC scheduler, parameter setting, etc. The user-leveltracer 222 can include tracing operations that can (i) track userbehavior in a cell, (ii) track user RF condition, (iii) track user datatraffic performance in different layers (MAC, Radio Link Control (RLC),Packet Data Convergence Protocol (PDCP)), and (iv) track user RFresource consumption.

FIG. 3 illustrates another view of the O-RAN architecture of someembodiments, with a more in-depth view of the near real-time RIC. Thearchitecture 300 includes an SMO 305 with a non-real-time RIC 310, adistributed near real-time RIC 315, and E2 nodes 320 (e.g., O-DU and/orO-CU nodes). The distributed near real-time RIC 315 includes messaginginfrastructure 340, a set of services (e.g., 350, 352, 354, and 356), ashared data layer 360, a database 370, and a set of terminationinterfaces (e.g., 380, 382, and 384). As shown, a set of embedded apps(e.g., 330, 332, and 334) uses this distributed near-RT RIC 315. Asfurther described below, the distributed near-RT RIC 315 is implementedby multiple RICs executing on multiple host computers in someembodiments.

As shown, the set of services include conflict mitigation services 350,app subscription management services 352, management services 354, andsecurity services 356. Additionally, the set of termination interfacesinclude O1 termination interface 380 connecting the SMO 305 to the nearreal-time RIC 315, A1 termination interface 382 connecting thenon-real-time RIC 310 to the near real-time RIC 315, and E2 terminationinterface 384 connecting the E2 nodes 320 to the near real-time RIC 315.Each of the apps, in some embodiments, is representative of the variousfunctions of the near-RT RIC 315 that use data sent from the E2 nodes320.

In some embodiments, the objective of the framework 300 is to offloadnear real-time functions that are computation-intensive, and provideresults back to the O-DU (e.g., via the E2 interface with E2 nodes 320).The results, in some embodiments, can be used to assist or enhance thereal-time decision in the MAC layer.

On each machine (e.g., each VM or Pod) that executes a control planeapplication, some embodiments configure a RIC SDK to serve as aninterface between the control plane application on the machine and a setof one or more elements of the RAN. In some embodiments, the RIC SDKprovides a set of connectivity APIs (e.g., a framework) through whichapplications can communicate with the distributed near real-time (RT)RIC implemented by two or more near real-time RICs. Examples of suchapplications include xApps, and other control plane and edgeapplications in some embodiments. In O-RAN, xApps perform control plane,monitoring, and data processing operations. The discussion belowregarding FIGS. 4 and 6-20 refers to control plane applications (e.g.,415, 615, 620, 715, 720, etc.). These control plane applications arexApps in an O-RAN system in some embodiments.

FIG. 4 illustrates deployment of RIC SDKs 405 on machines 410 thatexecute control plane applications 415 in some embodiments. As shown,one or more machines 410 execute on each of several host computers 407in one or more datacenters. In some embodiments, the RIC SDK 405 on eachmachine 410 includes a set of network connectivity processes thatestablish network connections to the set of RAN elements (e.g., E2 nodes320, shared data layer 360, management services 354, SMO 305, etc.) forthe control plane application. The RIC SDK processes allow the controlplane application on their machine to forego performing networkconnectivity operations. In some embodiments, the set of networkconnectivity processes of each RIC SDK of each machine establishes andmaintains network connections between the machine and the set of RANelements used by the control plane application of the machine, andhandles data packet transport to and from the set of RAN elements forthe control plane application.

The control plane application on each machine communicates with the setof RAN elements through high-level APIs 420 that the RIC SDK convertsinto low-level APIs 425. In some embodiments, at least a subset of thelow-level API calls 425 are specified by a standard specifying body.Also, in some embodiments, the high-level APIs 420 are made in ahigh-level programming language (e.g., C++), while the low-level APIcalls comprise low-level calls that establish and maintain networkconnections and pass data packets through these connections.

The set of RAN elements that the RIC SDK connects with the control planeapplication on its machine in some embodiments include RAN elements thatare produced and/or developed by different RAN vendors and/ordevelopers. These RAN elements include CUs 430 and DUs 435 of the RAN insome embodiments. Also, this SDK communicates with the CUs and DUsthrough the low-level, standard-specified E2 interface, while thecontrol plane application on the machine uses high-level API calls tocommunicate with the CUs and DUs through the MC SDK. In someembodiments, the high-level API calls specifying E2 interface operationsat a high-level application layer that do not include low-leveltransport or network operations.

Conjunctively, or alternatively, the set of RAN elements that the RICSDK connects with the control plane application 415 on its machine 410include network elements of the RIC. Again, these network elements insome embodiments include RAN elements that are produced and/or developedby different RAN vendors and/or developers. These RIC elements in someembodiments include shared data layer (SDL) 360, datapath input/output(I/O) elements, and application and management services 352 and 354 insome embodiments. FIG. 5 illustrates that some embodiments deployseveral near-RT RICs 505 to execute on several host computers 510 toimplement a distributed near-RT RIC 500 that includes the RIC componentsillustrated in FIGS. 3 and 4 . In some embodiments, one RIC 505 executeson each host computer that also executes a control plane application415. In other embodiments, a control plane application 415 can executeon a host computer that does not execute a RIC. For instance, in someembodiments, one or more control plane applications execute on one ormore host computers that have graphics processing units (GPUs), whileRICs do not execute on such host computers as they do not need theprocessing power of the GPUs.

Through the distributed near-RT RIC, the RIC SDK also connects itscontrol plane application to other control plane applications executingon other machines. In other words, the RIC SDK and the distributednear-RT RIC in some embodiments serve as a communication interfacebetween the control plane applications. In some embodiments, thedifferent control plane applications are developed by differentapplication developers that use the common set of RIC APIs tocommunicate with each other through the distributed near-RT RIC. In someof these embodiments, the distributed near-RT RIC adds one or moreparameters to the API calls as it forwards the API calls from onecontrol application to the other control application.

FIGS. 6-11 illustrate several examples of RIC architectures in which theRIC SDK and the distributed near-RT RIC establish the communicationinterface between control plane applications. These architectures aremutually exclusive in some embodiments, while in other embodiments twoor more of these architectures are used conjunctively. FIG. 6illustrates a near-RT MC 600 that executes on one host computer 605along with two machines 610 and 612 on which two control plane (CP)applications 615 and 620 execute. Through the MC SDKs 602 and 604executing on the machines 610 and 612, the MC 600 receives API callsfrom the CP application 615 and forwards the API calls to the CPapplication 620, and passes responses to these API calls from the secondCP application 620 to the first CP application 615. It also passes APIcalls from the second CP application 620 to the first CP application615, and responses from the first CP application 615 to the second CPapplication 620.

FIG. 7 illustrates two near-RT RICs 700 and 701 that execute on two hostcomputer 705 and 707 along with two machines 710 and 712 on which twocontrol plane applications 715 and 720 and two RIC SDKs 702 and 704execute. As shown, API calls from the first CP application 715 to thesecond CP application 720 are forwarded through the first RIC SDK 702,the first MC 700, the second MC 701 and the second RIC SDK 704. Thesecond CP application's responses to these API calls to the first CPapplication 715 traverse the reverse path from the second MC SDK 704,the second MC 701, the first MC 700, and the first MC SDK 702.

The API calls from second CP application 720 to the first CP application715 are forwarded through the second MC SDK 704, the second MC 701, thefirst RIC 700, and the first MC SDK 702, while responses to these APIcalls from the first CP application 715 to the second CP application 720are forwarded through the first RIC SDK 702, the first RIC 700, thesecond MC 701 and the second MC SDK 704.

FIG. 8 illustrates a near-RT RIC 800 that executes on first hostcomputer 805 to connect two control plane applications 815 and 820 thatexecute on two machines 810 and 812 operating on two other hostcomputers 806 and 807. Through the RIC SDKs 802 and 804 executing on themachines 810 and 812, the RIC 800 receives API calls from the CPapplication 815 and forwards the API calls to the CP application 820,and passes responses to these API calls from the second CP application820 to the first CP application 815. It also passes API calls from thesecond CP application 820 to the first CP application 815, and responsesfrom the first CP application 815 to the second CP application 820.

FIG. 9 illustrates a near-RT RIC 900 that executes on first hostcomputer 905 to connect two control plane applications 915 and 920 thatexecute on two machines 910 and 912 one of which operates on hostcomputer 905 while the other operates on host computer 906. Through theRIC SDKs 902 and 904 executing on the machines 910 and 912, the MC 900receives API calls from the CP application 915 and forwards the APIcalls to the CP application 920, and passes responses to these API callsfrom the second CP application 920 to the first CP application 915.Through these SDKs 902 and 904, the MC 900 also passes API calls fromthe second CP application 920 to the first CP application 915, andresponses from the first CP application 915 to the second CP application920.

FIG. 10 illustrates examples of the different standard specified APIsthat the distributed near-RT RIC platform of some embodiments supports.As shown, the distributed near-RT MC platform 1000 in some embodimentsuses the E2, O1, and A1 interfaces specified by the O-RAN standardspecifying body. It uses the E2 APIs to communicate with the E2 O-RANnodes, such as the O-CU-CPs 1002, O-CU-UPs 1004, and O-DUs 1006. It alsouses the A1 APIs to communicate with the non-real-time MC platform 1008and uses the O1 APIs to communicate the SMO 1010.

For each of these E2, A1, and O1 APIs, the MC SDKs 1015 providehigh-level counterpart APIs for the control plane applications 1020 thatuse the MC SDKs and the distributed near-RT RIC 1000 platform tocommunicate with the E2 nodes 1002-1006, the non-real-time MC platform1008 and the SMO 1010. FIG. 10 designates these high-level counterpartAPIs for the E2, O1, and A1 interfaces with a prime sign as the E2′ APIcalls, O1′ API calls, and A1′ API calls. These high-level counterpartAPIs are not specified by a standard body but are APIs that the MC SDKand/or distributed near-RT RIC convert into standard specified APIcalls.

FIG. 10 also shows several internal-RIC APIs for allowing the controlplane applications 1020 to communicate with each other through the MCSDKs and the distributed near-RT MC, and to communicate with one or moreelements of the distributed near0RT MC (e.g., shared data layer (SDL)360, datapath input/output (I/O) elements, and application andmanagement services 352 and 354).

Enablement APIs are the APIs that are used in some embodiments to allowthe control plane applications 1020 to communicate with each other. Asdescribed above by reference to FIGS. 6-9 , these APIs are passedthrough the distributed near-RT RIC in some embodiments. In otherembodiments, these APIs allow the MC SDKs of the control planeapplications to directly communicate with each other without traversingthrough any other components of the distributed near-RT RIC. For thisreason, FIG. 10 includes a dashed line between the MC SDKs 1015 of thetwo control plane applications 1020 to indicate that in some embodimentsthe MC SDKs 1015 of these applications communicate directly with eachother.

The enablement APIs in some embodiments include registration APIs,service discovery APIs as well as inter-app communication APIs.Registration APIs are used by the applications 1020 (e.g., xApps) tointroduce themselves to other applications 1020 by providing theirnetwork identifiers (e.g., their network address and available L4 ports)and providing their functionality (e.g., performing channel prediction).Service discovery APIs allow control plane applications 1020 (e.g.,xApps) to query the service directory (e.g., of the distributed near-RTRIC) for other control plane applications (e.g., other xApps) thatprovide a particular service. The inter-app communication APIs allow thecontrol plane applications to communicate with each other to pass alongdata and/or request certain operations.

Some embodiments deploy an SDL cache on the same host computer as acontrol plane application and use this cache to process at least asubset of the SDL storage access requests of the control planeapplication. In some embodiments, the control plane application and theSDL cache operate on a machine that executes on the host computer. Inother embodiments, the SDL cache operates on the same host computer butoutside of the machine on which the control plane application executes.In some of these embodiments, multiple control plane applicationsexecuting on the same host computer use a common SDL cache on that hostcomputer.

The SDL cache is part of a RIC that executes on the same host computeras the control plane application in some embodiments. In otherembodiments, the SDL cache is part of the RIC SDK that executes on thesame machine as the control plane application. In either of theseembodiments, a synchronizing process of the RIC or the RIC SDKsynchronizes the data stored in the SDL cache with the data stored inthe SDL storage.

In some embodiments, the SDL storage operates on a different hostcomputer than the host computer on which the control plane applicationexecutes, while in other embodiments at least a portion of the SDLstorage operates on the same host computer on which the control planeapplication executes. Also, in some embodiments, the RIC or the RIC SDKforwards SDL access requests from the control plane application to theSDL storage when the RIC SDK cannot process the SDL access requeststhrough the SDL cache. For instance, the RIC or the RIC SDK cannotprocess SDL access requests through the SDL cache when the SDL cachedoes not store data requested by the control plane application.

FIG. 11 illustrates embodiments in which the SDL cache 1102 is part ofeach MC SDK 1100 that executes on the same machine 1105 as its controlplane application 1110. As shown, the MC SDK 1100 includes a querymanager 112 that processes SDL requests from the CP application 1110 anda synchronizing service 1127 that synchronizes the data stored in theSDL cache 1102 with the data stored in an SDL storage 1150 of the SDL1155 of the distributed near-RT RIC 1130. In this example, the SDLstorage 1150 operates on a different host computer than the hostcomputer on which the control plane application 1110 executes. However,in other embodiments, at least a portion of the SDL storage 1150operates on the same host computer on which the control planeapplication 1110 executes.

When the control plane application 1110 uses a high-level API call toread or write data to the SDL storage, the query manager 1125 of the RICSDK 1100 first determines whether the data record being read or writtenis stored in the SDL cache 1102. If so, the query manager 1125 readsfrom or writes to this record. When this operation is a write operation,the synchronizing service 1127 writes the new data in real-time or onbatch basis to the SDL storage 1150. On the other hand, when querymanager 1125 of the RIC SDK 1100 determines that the data record beingread or written is not stored in the SDL cache 1102, it passes the APIcall to the SDL layer of the distributed near-RT MC to perform therequested read or write operation. When passing this API call, the MCSDK 1100 modifies the format of this call and/or modifies the parameterssupplied with this call in some embodiments.

Some embodiments provide various methods for offloading operations in anO-RAN (Open Radio Access Network) onto control plane (CP) or edgeapplications that execute on host computers with hardware acceleratorsin software defined datacenters (SDDCs). For instance, at the CP or edgeapplication operating on a machine executing on a host computer with ahardware accelerator, the method of some embodiments receives data, froman O-RAN E2 unit, for which it has to perform an operation. The methoduses a driver of the machine to communicate directly with the hardwareaccelerator to direct the hardware accelerator to perform a set ofcomputations associated with the operation. This driver allows thecommunication with the hardware accelerator to bypass an intervening setof drivers executing on the host computer between the machine's driverand the hardware accelerator. Through this driver, the application insome embodiments receives the computation results, which it thenprovides to one or more O-RAN components (e.g., to the E2 unit thatprovided the data, to another E2 unit, or to another xApp).

FIGS. 12-18 illustrate several different embodiments for offloadingO-RAN operations to CP or edge applications that have passthrough accessto the hardware accelerators of their host computers. Examples of such ahardware accelerator include a graphical processing unit (GPU), afield-programmable gate array (FPGA), an application-specific integratedcircuit (ASIC), and a structured ASIC.

FIG. 12 illustrates an example of CP or edge applications 1202 that havepassthrough access to hardware accelerator 1250 of their host computer1210 to perform some or all of their computations. As shown, eachapplication 1202 executes on a Pod 1204, which has accelerator drivers1212 with direct, passthrough access to the accelerator 1250 of theirhost computer 1210. Each Pod 1204 operates within (i.e., execute on) aVM 1206, which, in turn, executes over a hypervisor 1208 of the hostcomputer.

In some embodiments, a Pod is a small deployable unit of computing thatcan be created and managed in Kubernetes. A Pod includes a group of oneor more containers with shared storage and network resources, and aspecification for how to run the containers. In some embodiments, aPod's contents are always co-located and co-scheduled, and run in ashared context. A Pod models an application-specific logical hostcomputer; it contains one or more application containers thatcommunicate with each other. In some embodiments, the shared context ofa Pod is a set of an operating system namespaces (e.g., Linux cgroups).Within a Pod's context, the individual applications may have furthersub-isolations applied.

Each Pod's accelerator driver 1212 has direct accesses to the hardwareaccelerator 1250, and this access bypasses the hardware acceleratordrivers 1214 and 1216 of the VM 1206 and the hypervisor 1208. In someembodiments, the hypervisor 1208 executes over an operating system (notshown) of the host computer 1210. In these embodiments, the directaccess of each Pod's accelerator driver 1212 to the hardware accelerator1250 also bypasses the hardware accelerator driver of the operatingsystem.

To communicate with the hardware accelerator, each application 1202 insome embodiments communicates through the RIC SDK 1230 executing on itsPod. For instance, in some embodiments, each application 1202 useshigh-level APIs of the RIC SDK 1230 to communicate with the hardwareaccelerator 1250. The RIC SDK 1230 then converts the high-level APIs tolow-level APIs that are needed to communicate with machine's driver1212, which, in turn, relays the communication to the hardwareaccelerator 1250. The low-level APIs are provided by a first companyassociated with the sale of the hardware accelerator 1250, while the MCSDK 1230 is provided by a second company associated with thedistribution of the RIC SDK 1230. In some embodiments, the low-levelAPIs used by the RIC SDK 1230 are APIs specified in an API library 1232associated with the hardware accelerator 1250.

FIG. 13 illustrates a process 1300 that implements the method of someembodiments. The process 1300 is performed in response to an O-RANcomponent directing a CP or edge application to perform an operationthat requires the application to use a hardware accelerator of its hostcomputer. This process 1300 will be described below by reference to FIG.14 , which illustrates the application 1202 performing an operationbased on data received from an E2 node 1450.

As shown in FIG. 13 , the process 1300 starts when the application 1202(at 1305) receives data from an O-RAN E2 unit 1450 executing on the hostcomputer 1410. In some embodiments, the application 1202 subscribes fordata from the E2 unit 1450, and the data received at 1305 is in responseto this subscription. This subscription is made through the distributednear-RT RIC 1440 in some embodiments. The host computers 1210 and 1410of the application 1202 and the E2 unit 1450 operate in one SDDC in someembodiments. In other embodiments, these two host computers 1210 and1410 operate in two different physical locations. For example, the hostcomputer 1210 operates in a first location, while the host computer 1410operates at a second location close to a cell site of the O-RAN. In someembodiments, the second location does not have computers with hardwareaccelerators that perform complex operations including the receivedoperation.

The application 1202 receives (at 1305) the data from the E2 unit 1450through (1) the distributed near-RT RIC 1480 formed by near-RT RICs 1440and 1445 executing on host computers 1210 and 1410, and (2) the RIC SDK1230 executing on its Pod 1204. The application 1202 then uses (at 1310)the hardware accelerator 1250 to perform a set of computationsassociated with the operation.

To communicate with the hardware accelerator 1250, the application 1202uses high-level APIs provided by the RIC SDK 1230. The RIC SDK 1230 thenconverts the high-level APIs to low-level APIs specified in the APIlibrary 1232 associated with the hardware accelerator 1250. Theselow-level APIs are then communicated to the hardware accelerator 1250 bythe Pod's driver 1212 through its direct, passthrough access to theaccelerator 1250, which bypasses the drivers 1214 and 1216 of the VM1206 and hypervisor 1208. Through this driver 1212, the APIs specifiedin the API library 1232, and the RIC SDK 1230, the application 1202 alsoreceives the results of the operations (e.g., computations) performed bythe hardware accelerator 1250.

The application 1202 provides (at 1315) the result of its operation toone or more O-RAN components, such as the E2 unit 1450 that provided thedata that started the process 1300 or the SDL storage. This result isprovided through the RIC SDK 1230 and the distributed near-RT RIC 1480.In other embodiments, the application 1202 (through the RIC SDK 1230)provides the results of its operation to one or more other applications(applications other than the E2 unit that provided the data for whichthe application performed its operation) operating on another O-RAN E2unit or machine executing on the same host computer or on another hostcomputer as the application that uses the hardware accelerator 1250 toperform the operation. The process 1300 ends after 1315.

Other embodiments use the passthrough access for the O-RAN control oredge application in other deployment settings. For instance, FIG. 15illustrates another example of CP or edge applications 1502 that havepassthrough access to a hardware accelerator 1550 of their host computer1510 to perform some (or all) of their computations. In this example,each application 1502 (1) executes on a Pod 1504 that executes on a VM1506, and (2) uses the accelerator driver 1512 of this VM 1506 which hasdirect, passthrough access to the accelerator 1550 of its host computer1510. The VM 1506 executes over a hypervisor 1508 operating on the hostcomputer 1510. The VM's accelerator driver 1512 bypasses the hardwareaccelerator drivers 1516 of the hypervisor 1508. In some embodiments,the hypervisor 1508 executes over an operating system (not shown) of thehost computer 1510. In these embodiments, the direct access of the VM'saccelerator driver 1512 to the hardware accelerator 1550 bypasses thehardware accelerator driver of the operating system.

To use the hardware accelerator 1550, each application 1502 in someembodiments uses high-level APIs of the RIC SDK 1530 (executing on itsPod 1504) to communicate with the hardware accelerator 1550. The MC SDK1530 converts the high-level APIs to low-level APIs that are needed tocommunicate with VM's driver 1512, which, in turn, relays thecommunication to the hardware accelerator 1550. In some embodiments, thelow-level APIs used by the RIC SDK 1530 are APIs specified in an APIlibrary 1532 associated with the hardware accelerator 1550. This APIlibrary 1532 is part of the driver interface of the VM 1506.

FIG. 16 illustrates yet another example of CP or edge applications 1602that has passthrough access to a hardware accelerator 1650 of their hostcomputer 1610 to perform some or all of their computations. In thisexample, each application 1602 (1) executes on a VM 1604 that executeson a hypervisor 1606 operating on the host computer 1610, and (2) usesthe accelerator driver 1612 of its VM 1604, which has direct,passthrough access to the accelerator 1650 of its host computer 1610.

The VM's accelerator driver 1612 bypasses the hardware acceleratordrivers 1616 of the hypervisor 1606. In some embodiments, the hypervisor1606 executes over an operating system (not shown) of the host computer1610. In these embodiments, the direct access of the VM's acceleratordriver 1612 to the hardware accelerator 1650 bypasses the hardwareaccelerator driver of the operating system.

To use the hardware accelerator 1650, each application 1602 in someembodiments uses high-level APIs of the RIC SDK 1630 (executing on itsVM 1604) to communicate with the hardware accelerator 1650. The RIC SDK1630 converts the high-level APIs to low-level APIs that are needed tocommunicate with the VM's driver 1612, which, in turn, relays thecommunication to the hardware accelerator 1650. In some embodiments, thelow-level APIs used by the RIC SDK 1630 are APIs specified in an APIlibrary 1632 associated with the hardware accelerator 1650. This APIlibrary 1632 is part of the driver interface of the VM 1606.

One of ordinary skill will realize that the passthrough access for theO-RAN control or edge application is used in other deployment settingsin other embodiments. For instance, instead of operating on Pods, theapplications in other embodiments operate on containers. Theseembodiments then use the hardware accelerator drivers of their Pods orVMs to have passthrough access to the hardware accelerators for thecontrol or edge application. In some of these embodiments, the controlor edge application communicates with the hardware accelerator throughits associated RIC SDK and communicates with other O-RAN components (toreceive data and to provide results of its processing of the data)through its associated RIC SDK and the distributed near-RT MC connectingthe O-RAN components and the application. In some embodiments, thecontrol or edge application in these embodiments performs processessimilar to process 1300 of FIG. 13 .

The above-described direct, passthrough access to hardware acceleratorsis quite beneficial for O-RANs. The MC is all about decoupling theintelligence that used to be embedded within the RAN software (CU andDU) and moving it to the cloud. One benefit of this is to use moreadvanced computing in the cloud for the xApp and edge operations (e.g.,for ML, deep learning, reinforcement learning for control algorithms,etc.). A DU close to a cell site typically cannot run advancecomputations because it would not be economically feasible to put GPUsat each cell site as network capital expenditure will be very high.

By using the hardware accelerator (e.g., GPUs, FPGAs, eASICs, ASICs) inthe SDDC, some embodiments run complex control algorithms in the cloud.Examples of such xApps include Massive MIMO beam forming and Multi-user(MU) MIMO user pairing, which were described above. Generally, any xAppwhose computations can benefit from massive parallelization would gainthe benefit of GPUs or other accelerators. The use of ASICs isbeneficial for channel decoding/encoding (turbo encoding, LDPC encoding,etc.). In some embodiments, the RIC is typically on the same worker VMas xApps. However, in other embodiments, the RICs executes on adifferent host computer so that more xApps that need GPUs and otherhardware accelerators can run on the hosts with the GPUs and/or otherhardware accelerators.

FIG. 17 illustrates a process that some embodiments use to deploy O-RANapplications with direct, passthrough access to the hardwareaccelerators of their host computers. To install an application on ahost computer, the process 1700 selects (at 1705) a set of one or moreinstallation files that includes a description for configuringpassthrough access for the application to a hardware accelerator of thehost computer. In some embodiments, the set of files includes onedescription file that specifies direct, passthrough access for theapplication to the hardware accelerator of its computer.

The process 1700 uses (at 1710) the set of installation files toconfigure, based on the description relating to the passthrough access,a program executing on the host computer to pass calls from a particularhardware accelerator driver associated with the application to thehardware accelerator without going through an intervening set of one ormore drivers for the hardware accelerator that executes on the hostcomputer between the particular hardware accelerator driver and thehardware accelerator. This configuration allows the application tobypass the intervening set of drivers when directing the hardwareaccelerator to perform operations for the application and to receive theresults of the operations from the hardware accelerator.

The program that is configured at 1710 in some embodiments is the host'soperating system, while in other embodiments it is a hypervisorexecuting on the host computer. In still other embodiments, the programis a virtual machine (VM) and the application operates on a Pod orcontainer that executes on the VM. The process 1700 completes (at 1715)the installation of the application by processing the remaining set ofinstallation files selected at 1705, and then ends. In otherembodiments, the process 1700 performs the configuration of the programas its last operation instead of as its first operation at 1710. Instill other embodiments, it performs this configuration as one of itsintervening installation operations.

Before performing the selection and configuration, the deploymentprocess of some embodiments identifies the host computer from severalhost computers as the computer on which the application should beinstalled. The process in some embodiments identifies the host computerby determining that the application requires a hardware accelerator,identifying a set of host computers that each comprise a hardwareaccelerator, and selecting the host computer from the set of hostcomputers. The process selects the host computer by (1) determining thatthe application will need to communicate with a set of one or more otherapplications that execute on the selected host computer, and (2)selecting the host computer as the set of other applicationssimultaneously executes on the host computer. This installation of theapplication with the set of other applications on the selected hostcomputer reduces communication delay between the application and the setof other applications.

Some embodiments have the hardware accelerator drivers of the O-RANcontrol or edge applications communicate with virtualized hardwareaccelerators that are offered by an intervening virtualizationapplication (e.g., hypervisor) that executes on the same host computeras the application. For instance, the method of some embodiments deploysa virtualization application on a host computer for sharing resources ofthe host computer among several machines executing on the host computer.This computer has a first set of one or more physical hardwareaccelerators.

The method deploys several applications on several machines to performseveral O-RAN related operations for a set of O-RAN components. Throughthe virtualization application, the method defines a second set of twoor more virtual hardware accelerators that are mapped to the first setof physical hardware accelerators by the virtualization application. Themethod assigns different virtual hardware accelerators to differentapplications. The method also configures the applications to use theirassigned virtual hardware accelerators to perform their operations.

In some embodiments, the deployed machines are Pods, and theapplications are deployed to execute on the Pods. At least two Podsexecute on one VM that executes above the virtualization application.This VM includes a hardware accelerator driver that is configured tocommunicate with two different virtual hardware accelerators for the twoapplications executing on the two Pods. In other embodiments, multiplePods execute on one VM that executes above the virtualizationapplication, and each Pod has a hardware accelerator driver that isconfigured to communicate with a virtual hardware accelerator that isassigned to that driver.

FIG. 18 illustrates an example of CP or edge applications 1802 that havepassthrough access to virtual hardware accelerator 1852 and 1854 definedby a hypervisor 1808 executing on their host computer 1810 in order toperform some or all of their computations. As shown, each application1802 executes on a Pod 1804, which has accelerator drivers 1812 withdirect, passthrough access to virtual accelerators 1852 or 1854. EachPod 1804 operates within (i.e., execute on) a VM 1806, which, in turn,executes over a hypervisor 1808 of the host computer 1810.

Each Pod's accelerator driver 1812 has direct access to the virtualaccelerator 1852 or 1854, and this access bypasses the acceleratordrivers 1814 and 1816 of the VM 1806 and the hypervisor 1808. In someembodiments, the hypervisor 1808 executes over an operating system (notshown) of the host computer 1810. In these embodiments, the directaccess of each Pod's accelerator driver 1812 to the virtual accelerator1852 or 1854 also bypasses the hardware accelerator driver of theoperating system.

As shown, the virtual accelerators 1852 and 1854 communicate to thehardware accelerator 1850 through the accelerator manager 1860 of thehypervisor 1808. The accelerator manager 1860 allows the virtualaccelerators 1852 and 1854 (and in turn their associated applications1802) to share one hardware accelerator 1850, while operating with thisaccelerator 1850 as if it is dedicated to their respective applicationsand Pods 1802 and 1804. Examples of such a hardware accelerator 1850include a graphical processing unit (GPU), a field-programmable gatearray (FPGA), an application-specific integrated circuit (ASIC), and astructured ASIC.

To communicate with its virtual accelerator 1852 or 1854, eachapplication 1802 in some embodiments communicates through the RIC SDK1830 executing on its Pod 1804. For instance, in some embodiments, eachapplication 1802 uses high-level APIs of the RIC SDK 1830 to communicatewith its virtual accelerator 1852 or 1854. The RIC SDK 1830 thenconverts the high-level APIs to low-level APIs that are needed tocommunicate with each machine's driver 1812, which, in turn, relays thecommunication to the virtual accelerator 1852 or 1854. The virtualaccelerator 1852 or 1854 then relays the communications to the hardwareaccelerator 1850 through the accelerator manager 1860.

As mentioned above by reference to FIG. 12 , in some embodiments, thelow-level APIs are provided by a first company associated with the saleof the hardware accelerator 1850, while the RIC SDK 1830 is provided bya second company associated with the distribution of the RIC SDK 1830.In some embodiments, the low-level APIs used by the RIC SDK 1830 areAPIs specified in an API library 1832 associated with the hardwareaccelerator 1850. Each application 1802 receives the results of theoperations of the hardware accelerator 1850 through the acceleratormanager 1860, its virtual accelerator 1852 or 1854, its driver 1812, andits RIC SDK 1830.

Having described the distributed near real-time RIC and the RIC SDK ofsome embodiments, the following describes the MAC scheduler anduser-level tracing applications of some embodiments. In someembodiments, one or more applications (e.g., xApps) are deployed toperform MAC scheduling and/or user-level tracing. Examples of MACscheduling operations that can be performed by applications running ontop of the distributed near real-time RIC in some embodiments includebeamforming weight calculation, RF condition prediction, and MU-MIMOpairing suggestion. Examples of user-level tracing functions that can beperformed by applications running on top of the distributed nearreal-time RIC in some embodiments include operations to (1) track userbehavior in a cell, (2) track user RF condition, (3) track user datatraffic performance in different layers (MAC, RLC, PDCP), and (4) trackuser RF resource consumption. In some embodiments, outputs of theuser-level tracing applications may be used by one or more of the MACscheduler applications.

FIG. 19 illustrates data flow for a set of MAC scheduler applications1905-1915 that operate on top of the distributed near real-time RIC1940. These applications may operate in any of the manners describedabove by reference to FIGS. 3-18 in some embodiments. The MAC schedulerapplication includes a beamforming weight calculator application 1905,an RF condition prediction application 1910, and an MU-MIMO pairingsuggestion application 1915.

As shown, each of these applications 1905-1915 receives data through thedistributed near real-time MC 1940 from one or more DUs 1920 (which, asnoted above, are examples of E2 nodes) and provides output data to theDUs 1920. In different embodiments, the MAC scheduler applications1905-1915 may provide their output data to the same DU(s) from whichcorresponding input data was received or different DU(s) from which thecorresponding input data was received.

In order for one of the applications 1905-1915 (or other applications)to receive data from the DUs 1920 or other E2 nodes, in some embodimentsan application subscribes to a specific type of data with an E2 node,via the distributed near real-time RIC 1940. The application sends asubscription request to the RIC (e.g., via the set of connectivity APIsof the RIC SDK), which records the request. Though not shown in FIG. 19, the subscription management services 352 shown in FIG. 3 handle thesesubscription requests and store the subscription information (e.g.,which data from which E2 nodes needs to be forwarded to whichapplications). The RIC generates a subscription to send to the set ofone or more E2 nodes specified by the requesting application (in thecorrect E2 format) and sends this data to the correct nodes via the E2interface. The applications can request data from one or more E2 nodes(e.g., DUs and CUs at the same base station, multiple DUs and/ormultiple CUs at different base stations, etc.). If the E2 nodes sendsubscription acknowledgements back to the RIC (i.e., indicating thatthey will provide the requested data as it becomes available), the RICuses the stored subscription information to provide confirmation to thecorrect requesting application(s).

FIG. 20 conceptually illustrates a process 2000 of some embodiments forthe distributed near real-time RIC to provide subscription data from anE2 node to applications (e.g., one or more of the MAC schedulerapplications 1905-1915). This process 2000 will be described in part byreference to FIG. 19 .

As shown, the process 2000 begins by receiving (at 2005) data from an E2node. The distributed near real-time RIC 1940 receives this data at theE2 termination interface 1925 in some embodiments. This can be any sortof data that the E2 node provides to the distributed near real-time MC,examples of which are described below for the MAC scheduler applications1905-1915. In some embodiments, the E2 nodes are specified to exposedifferent types of data via report interfaces with the distributed nearreal-time MC.

The process 2000 then identifies (at 2010) one or more applications thatare subscribed to the received data based on stored subscriptionforwarding information. The subscription forwarding information isstored when an application requests a subscription to a particular typeof data from a particular set of E2 nodes and that subscription requestis acknowledged by the E2 node(s). In different embodiments, the E2termination interface 1925, the subscription management service (notshown in this figure), or the messaging infrastructure 1930 stores thissubscription forwarding information so as to route data between the E2nodes (e.g., the DUs 1920) and the applications (e.g., the MAC schedulerapplications 1905-1915). Next, the process 2000 provides the data (at2015) to the one or more identified applications. In some embodiments,this data is provided via the messaging infrastructure 1930 (e.g.,various aspects of the RIC SDK as described above). The process 2000then ends.

The MAC scheduler applications 1905-1915 use different types of inputdata from the E2 nodes to produce different types of output data, whichare in turn provided back to one or more E2 nodes (e.g., to the DUs thatprovided the input data). FIG. 21 conceptually illustrates a process2100 of some embodiments for the distributed near real-time RIC toprovide data output by an application (e.g., one of the MAC schedulerapplications 1905-1915) to one or more E2 nodes (e.g., one or more ofthe DUs 1920). The process 2100 will be described in part by referenceto FIG. 19 .

As shown, the process 2100 begins by receiving (at 2105) output datafrom an application. The application may be one of the MAC schedulerapplications 1905-1915, a user-level tracing application, or anotherapplication that provides data back to one or more E2 nodes. Examples ofdata that the MAC scheduler applications 1905-1915 provide to the E2nodes will be described below. In some embodiments, the data is providedvia the messaging infrastructure 1930 (e.g., various aspects of the RICSDK described above) in such a way that specifies that the data is to besent to E2 nodes (e.g., as opposed to being sent to another applicationor stored in the SDL storage).

The process then identifies (at 2110) one or more E2 nodes that need toreceive the data. In some embodiments, the data from the applicationindicates a type of data that the distributed near real-time RIC uses toidentify its destination. In other embodiments, the subscriptionforwarding information stored by the distributed near real-time RICindicates which applications output data to which E2 nodes, and usesthis to identify the recipient E2 nodes based on the specificapplication that provided the output data. As noted above, thisinformation may be stored in different embodiments by the E2 terminationinterface 1925, the subscription management service (not shown in FIG.19 ), or the messaging infrastructure 1930. Next, the process 2100 sends(at 2115) the data to the one or more identified E2 nodes (e.g., via theE2 termination interface 1925). The process 2100 then ends.

As noted, different MAC scheduler applications receive different typesof data and generate different types of output data. Each of theseapplications receives specific types of data from the DU (via the E2interface and the RIC framework) and provides its output data to the DU.These applications may also receive other information (e.g., to performmore complex operations than would be available at the DU) from othersources (e.g., other applications, such as the user-level tracingapplications).

The beamforming weight calculator application 1905 of some embodimentscomputes a beamforming weight matrix or a beam index/beam identifier fora UE (e.g., a mobile device). This weight matrix or beam index specifieshow a base station should transmit signals to the UE. The DU 1920 usesthe matrix to control the MIMO antenna array gain/phasing in the RU foruser data transmission and reception in some embodiments. The DU 1920,in some embodiments, can use any of several different beamformingmethods, including predefined-beam beamforming, weight-based dynamicbeamforming based on real-time-updated weights (for which thebeamforming weight calculator application 1905 calculates the weights),attribute-based dynamic beamforming based on real-time-updated beamattributes (for which the beamforming weight calculator application 1905or other applications could compute attributes), andchannel-information-based beamforming.

From the DU 1920 (via the RIC), the beamforming weight calculatorapplication 1905 receives information related to an uplink SoundingReference Signal (UL SRS), such as an UL channel response matrix and/orphase (I) and quadrature (Q) data exposed by the DU 1920 via a reportinterface. In some embodiments, the input to the beamforming weightcalculator application 1905 can include multiple options based on the ULSRS, such as raw SRS received data and an SRS channel responses matrixfrom a channel estimate. In some embodiments, the DU also indicates itssupported beamforming method (e.g., weight-based) as well asmethod-dependent information such as the beamforming type (e.g.,frequency, time, or hybrid) as well as the number of beams.

The beamforming weight calculator application 1905 calculates andprovides to the DU 1920 (e.g., the same DU from which the UL SRS channelresponse matrix was received), through the MC, the beamforming matrixfor the UE via an exposed control interface of the DU 1920. In someembodiments, the information provided to the DU includes a set of UEidentifiers and a beamforming weight matrix (e.g., for each UE) thatspecifies a I/Q data per antenna element for the UE, or a beamidentifier that should be used for a certain UE.

The beamforming weight calculator algorithm, in some embodiments,evaluates the optimal beam-forming weights to reach the user. Someembodiments use traditional signal processing algorithms that are basedon channel models. Alternatively, or conjunctively, machine-learningbased algorithms that utilize raw data inputs may be used, which in somecases require feedback from the DU 1920. In some embodiments, the outputbeamforming weight matrix could also be mapped to a beam index from apre-designed beam set. Machine-learning based beamforming calculationscould, for example, look at where users are located or determine thepopulation density of UEs in an area and design beams differently basedon this information. For instance, for locations that are denser, thebeamforming weight calculator application 1905 might provide a weightmatrix with more precise beams, whereas less precision is required forless dense areas. Similarly, the beamforming weight calculatorapplication 1905 could take into account the type of traffic beingcarried and design a beamforming weight matrix with a better guaranteeof reliability for more important traffic. The data required for thesecomputations could come from a combination of the DU, other E2 nodes atthe same base station, other applications, etc.

The RF condition prediction application 1910 of some embodimentscomputes the RF condition of a UE; that is, a predicted downlink (DL)and/or uplink (DL) channel condition (e.g., including DL signal to noiseinterference and noise ratio (SINR), precoder matrix indicators (PMI),and rank) for an upcoming (e.g., next or near-future) scheduling window.From the DU 1920 (via the RIC), the RF condition prediction application1910 receives at least a DL and/or UL channel condition report exposedby the DU 1920 via a report interface. The channel condition report mayinclude Wideband or Subband channel quality information (CQI), PMI (usedto signal preferred weights), and rank indicators (RI, used to indicatea number of layers required during layer mapping). In some embodiments,the input metrics for the RF condition prediction application 1910 couldalso include supportive information such as UE distance, UE positioning,etc. (e.g., received from the DU or from other sources).

The RF condition prediction application 1910 calculates and provides tothe DU 1920 (e.g., the same DU from which the channel condition reportwas received), through the MC, the predicted UL and/or DL channelcondition. The output metrics can include, in some embodiments, thepredicted channel condition of the user for the upcoming (e.g., next ornear-future) scheduling window, as well as predicted downlink and uplinkSINR, a precoding matrix (e.g., if applicable), and SU-MIMO layers. Insome embodiments, these output metrics are used by the DU for the userlink adaptation on physical downlink control channel (PDCCH), physicaldownlink shared channel (PDSCH), and physical uplink shared channel(PUSCH) transmissions. Some embodiments utilize traditional signalprocessing algorithms based on channel and mobility models.Alternatively, or conjunctively, some embodiments also use machinelearning based algorithms using data inputs and potentially otherfactors, such as site layout.

The MU-MIMO pairing suggestion application 1915 of some embodimentsdetermines UE pairing suggestions and computes SINR impact assessmentsfor such pairings. This pairing suggestion indicates which UEs should bepaired for MU-MIMO operations. From the DU 1920 (via the RIC), theMU-MIMO pairing suggestion application 1915 receives UE-specificbeamforming weight matrices or other UE-specific beamforming data (e.g.,a beam index) exposed by the DU 1920 via a report interface (e.g., thesame beamforming weight matrices computed by the beamforming weightcalculator application 1905). In some embodiments, additionalinformation such as the UE RF condition estimate (e.g., as computed bythe RF condition prediction application 1910), user data demand, andother supportive metrics may be used by the MU-MIMO pairing suggestionapplication 1915.

The MU-MIMO pairing suggestion application 1915 calculates and providesto the DU 1920 (e.g., the same DU from which the UL SRS channel responsematrix was received), through the RIC, UE pairing suggestion and SINRimpact assessment via an exposed control interface of the DU 1920. Insome embodiments, each pairing suggestion includes a set of UEidentifiers identifying the UEs that should be paired. Optionally, thepairing suggestions of some embodiments include beamforming weights or abeam identifier for each UE in the pairing as well as a DL transmitpower allocation for each UE in the pairing. Some embodiments alsoinclude an SINR reduction for each UE identifier if the set of UEs isco-scheduled with the indicated beamforming weights and transmit powerallocation.

The DU 1920 can use this information to select users for RF schedulingand to determine transmission efficiencies. Some embodiments usetraditional signal processing algorithms based on information theory andcross-channel covariance evaluation. Alternatively, or conjunctively,some embodiments use machine learning based algorithms using the datainputs, which in some cases requires feedback from the DU 1920. Thismachine learning can factor in additional information; for example, insome cases the MU-MIMO pairing suggestion application 1915 might avoidpairing users that have different performance targets (e.g., differentlevels of importance to the data being sent to these UEs).

FIG. 22 illustrates data flow for a user-level tracing application 2200as well as other applications 2205 and 2210 that operate on top of thedistributed near real-time RIC 2215. These applications may operate inany of the manners described above by reference to FIGS. 3-18 in someembodiments. It should also be noted that while only a single user-leveltracing application 2200 is shown, some embodiments can include numeroussuch applications that perform different tracing operations. Thesetracing operations can include operations to (i) track user behavior ina cell, (ii) track user RF condition, (iii) track user data trafficperformance in different layers (MAC, Radio Link Control (RLC), PacketData Convergence Protocol (PDCP)), and/or (iv) track user RF resourceconsumption, as well as other tracking/tracing functions.

The user-level tracing application 2200 of some embodiments receivesdata through the distributed near real-time RIC 2215 from one or moreDUs 2220 (which, as noted above, are examples of E2 nodes) and providesoutput data to the other applications 2205 and 2210 (which couldinclude, e.g., any of the MAC scheduler applications 1905-1915). As anexample, another application might perform analysis on the user dataperformance received from the user-level tracing applications 2200,determine that certain performance is inadequate, and modify how the RANis treating the user traffic. In different embodiments, the user-leveltracing application 2200 provides some or all of its output data to oneor more DUs 2220.

As with the MAC scheduler applications 1905-1915, the user-level tracingapplication 2200 subscribes to specific types of data with the DUs 2220(or with other E2 nodes) via the distributed near real-time RIC 2215.The application 2200 sends a subscription request to the RIC (e.g., viathe set of connectivity APIs of the RIC SDK), which records the request.Though not shown in FIG. 22 , the subscription management services 352shown in FIG. 3 handle these subscription requests and store thesubscription information (e.g., which data from which E2 nodes needs tobe forwarded to which applications). The MC generates a subscription tosend to the set of one or more E2 nodes specified by the requestingapplication (in the correct E2 format) and sends this data to thecorrect nodes via the E2 termination interface 2225. The application2200 can request data from one or more E2 nodes (e.g., DUs and CUs atthe same base station, multiple DUs and/or multiple CUs at differentbase stations, etc.). If the E2 nodes send subscription acknowledgementsback to the RIC (i.e., indicating that they will provide the requesteddata as it becomes available), the RIC uses the stored subscriptioninformation to provide confirmation to the correct requestingapplication(s).

Data can then be received by the user-level tracing application 2200 ina manner similar to that described above by reference to FIG. 20 . Insome embodiments, the DU exposes report interfaces to provide variousmetrics to the user level tracing application 2200. These metrics caninclude selected Radio Resource Control (RRC) messages, traffic volumeand performance for any of MAC, radio link control (RLC), and/or packetdata convergence protocol (PDCP), RF condition information, RF resourcesconsumption, and/or other metrics. In some embodiments, messages overthese interfaces to the RIC are triggered based on user behavior and/orperiodic reporting.

As noted, the output data from the user-level tracing application 2200is provided to other applications (e.g., applications 2205 and 2210) insome embodiments. The output data, as noted, may include tracking datafor (i) user behavior in a cell, (ii) user RF condition, (iii) user datatraffic performance in different layers (MAC, RLC, PDCP), and/or (iv)user RF resource consumption. This information could be used by machinelearning algorithms in the MAC scheduler applications (e.g., to performmore accurate beamforming weight matrix computations).

The data can either be provided from the user-level tracing applicationsto these other applications as the data is generated or stored in a datastorage of the RIC for later retrieval by the other applications. In theexample shown in FIG. 22 , the user-level tracing application 2200provides data directly to the first other application 2205 via themessaging infrastructure 2230 of the distributed near real-time RIC.Examples of this messaging infrastructure in different embodiments aredescribed above (e.g., by reference to FIGS. 6-9 ). This allows the datato be provided quickly to the other application 2205.

If the other application that uses the user-level tracing data does notrequire data as quickly as possible, in some embodiments the user-leveltracing application 2200 stores the data to a location in the datastorage 2240 via the shared data layer (SDL) 2245. The operation of theSDL according to some embodiments is described above (e.g., by referenceto FIG. 11 ). When the application 2210 requires the data from theuser-level tracing application 2200, this application 2210 can retrievethe data from the data storage 2240 via the SDL 2245.

One example of a user-level tracing application of some embodimentsincludes QoS scheduling optimization with the goal of adjusting a user'sscheduling priority for an RF resource to optimize the service quality.The input for some embodiments of this application includes a servicequality target from a user subscription. In some embodiments, thealgorithm used by the application is based on the QoS target andobserved user traffic performance and can be used to determine that auser's resource allocation is insufficient. The algorithm format, insome embodiments, can be logic-based or machine learning-based. In someembodiments, the output includes a recommendation issued to a MACscheduler application to adjust the traffic priority or link adaptationin order to improve performance.

FIG. 23 conceptually illustrates an electronic system 2300 with whichsome embodiments of the invention are implemented. The electronic system2300 may be a computer (e.g., a desktop computer, personal computer,tablet computer, server computer, mainframe, a blade computer etc.), orany other sort of electronic device. Such an electronic system 2300includes various types of computer-readable media and interfaces forvarious other types of computer-readable media. Electronic system 2300includes a bus 2305, processing unit(s) 2310, a system memory 2325, aread-only memory 2330, a permanent storage device 2335, input devices2340, and output devices 2345.

The bus 2305 collectively represents all system, peripheral, and chipsetbuses that communicatively connect the numerous internal devices of theelectronic system 2300. For instance, the bus 2305 communicativelyconnects the processing unit(s) 2310 with the read-only memory 2330, thesystem memory 2325, and the permanent storage device 2335.

From these various memory units, the processing unit(s) 2310 retrieveinstructions to execute and data to process in order to execute theprocesses of the invention. The processing unit(s) 2310 may be a singleprocessor or a multi-core processor in different embodiments.

The read-only-memory (ROM) 2330 stores static data and instructions thatare needed by the processing unit(s) 2310 and other modules of theelectronic system 2300. The permanent storage device 2335, on the otherhand, is a read-and-write memory device. This device 2335 is anon-volatile memory unit that stores instructions and data even when theelectronic system 2300 is off. Some embodiments of the invention use amass-storage device (such as a magnetic or optical disk and itscorresponding disk drive) as the permanent storage device 2335.

Other embodiments use a removable storage device (such as a floppy disk,flash drive, etc.) as the permanent storage device 2335. Like thepermanent storage device 2335, the system memory 2325 is aread-and-write memory device. However, unlike storage device 2335, thesystem memory 2325 is a volatile read-and-write memory, such asrandom-access memory. The system memory 2325 stores some of theinstructions and data that the processor needs at runtime. In someembodiments, the invention's processes are stored in the system memory2325, the permanent storage device 2335, and/or the read-only memory2330. From these various memory units, the processing unit(s) 2310retrieve instructions to execute and data to process in order to executethe processes of some embodiments.

The bus 2305 also connects to the input and output devices 2340 and2345. The input devices 2340 enable the user to communicate informationand select commands to the electronic system 2300. The input devices2340 include alphanumeric keyboards and pointing devices (also called“cursor control devices”). The output devices 2345 display imagesgenerated by the electronic system 2300. The output devices 2345 includeprinters and display devices, such as cathode ray tubes (CRT) or liquidcrystal displays (LCD). Some embodiments include devices such as atouchscreen that function as both input and output devices.

Finally, as shown in FIG. 23 , bus 2305 also couples electronic system2300 to a network 2365 through a network adapter (not shown). In thismanner, the computer can be a part of a network of computers (such as alocal area network (“LAN”), a wide area network (“WAN”), or an Intranet,or a network of networks, such as the Internet. Any or all components ofelectronic system 2300 may be used in conjunction with the invention.

Some embodiments include electronic components, such as microprocessors,storage and memory that store computer program instructions in amachine-readable or computer-readable medium (alternatively referred toas computer-readable storage media, machine-readable media, ormachine-readable storage media). Some examples of such computer-readablemedia include RAM, ROM, read-only compact discs (CD-ROM), recordablecompact discs (CD-R), rewritable compact discs (CD-RW), read-onlydigital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a varietyof recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.),flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.),magnetic and/or solid state hard drives, read-only and recordableBlu-Ray® discs, ultra-density optical discs, any other optical ormagnetic media, and floppy disks. The computer-readable media may storea computer program that is executable by at least one processing unitand includes sets of instructions for performing various operations.Examples of computer programs or computer code include machine code,such as is produced by a compiler, and files including higher-level codethat are executed by a computer, an electronic component, or amicroprocessor using an interpreter.

While the above discussion primarily refers to microprocessor ormulti-core processors that execute software, some embodiments areperformed by one or more integrated circuits, such asapplication-specific integrated circuits (ASICs), or field-programmablegate arrays (FPGAs). In some embodiments, such integrated circuitsexecute instructions that are stored on the circuit itself.

As used in this specification, the terms “computer”, “server”,“processor”, and “memory” all refer to electronic or other technologicaldevices. These terms exclude people or groups of people. For thepurposes of the specification, the terms display or displaying meansdisplaying on an electronic device. As used in this specification, theterms “computer-readable medium,” “computer-readable media,” and“machine-readable medium” are entirely restricted to tangible, physicalobjects that store information in a form that is readable by a computer.These terms exclude any wireless signals, wired download signals, andany other ephemeral signals.

While the invention has been described with reference to numerousspecific details, one of ordinary skill in the art will recognize thatthe invention can be embodied in other specific forms without departingfrom the spirit of the invention. For instance, a number of the figuresconceptually illustrate processes. The specific operations of theseprocesses may not be performed in the exact order shown and described.The specific operations may not be performed in one continuous series ofoperations, and different specific operations may be performed indifferent embodiments. Furthermore, the process could be implementedusing several sub-processes, or as part of a larger macro process.

Also, several embodiments described above only show one hardwareaccelerator per host computer. However, one of ordinary skill willrealize that the methodology and architecture of some embodiments can beused to provide direct, passthrough access to multiple hardwareaccelerators on one host computer. Thus, one of ordinary skill in theart would understand that the invention is not to be limited by theforegoing illustrative details, but rather is to be defined by theappended claims.

1-24. (canceled)
 25. A method for performing radio access network (RAN) functions in a cloud, the method comprising: at an application that executes on a machine deployed on a host computer in the cloud, the application operating on top of a distributed RAN intelligent controller (dRIC) that executes across the host computer as well as a plurality of additional host computers in the cloud: receiving data, via the dRIC, from a RAN component; using the received data to generate information related to at least one user device, thereby offloading the generation of said information from the RAN component; and providing the generated information to the dRIC for distribution to a consumer of the generated information.
 26. The method of claim 25, wherein: the application is a first application that executes on a first machine deployed on a first host computer in the cloud; and providing the generated information to the dRIC comprises storing the information in a database of the dRIC for later use by a second application that executes on top of the dRIC on a second machine deployed on a second host computer in the cloud.
 27. The method of claim 26, wherein the second host computer and second machine are the same as the first host computer and first machine such that the second application that is the consumer of the stored information executes on top of the dRIC on the same machine as the first application.
 28. The method of claim 26, wherein: the first and second machines are different machines; and the information is stored in the database of the dRIC by the first application via a shared data layer (SDL) and later retrieved by the different application via the SDL.
 29. The method of claim 25, wherein providing the generated information to the dRIC comprises providing the generated information to a different application via a messaging infrastructure of the dRIC.
 30. The method of claim 25, wherein the consumer of the generated information is the RAN component from which the data is received.
 31. The method of claim 30, wherein the RAN component is an Open RAN Distributed Unit (O-DU).
 32. The method of claim 25 further comprising, prior to receiving the data: sending a subscription request for the data to the RAN component via the dRIC; and receiving a subscription acknowledgment from the RAN component via the dRIC.
 33. The method of claim 32, wherein: the dRIC receives the subscription request from the application through a set of APIs of the dRIC; and the dRIC converts the subscription request received from the application into a subscription request in a format recognized by the RAN component.
 34. The method of claim 25, wherein using the received data to generate information related to at least one user device comprises applying a machine learning algorithm to the received data.
 35. A non-transitory machine-readable medium storing an application which when executed by at least one processing unit of a host computer performs radio access network (RAN) functions in a cloud, the application executing on a machine deployed on the host computer, the application operating on top of a distributed RAN intelligent controller (dRIC) that executes across the host computer as well as a plurality of additional host computers in the cloud, the user-level tracing application comprising sets of instructions for: receiving data, via the dRIC, from a RAN component; using the received data to generate information related to at least one user device, thereby offloading the generation of said information from the RAN component; and providing the generated information to the dRIC for distribution to a consumer of the generated information.
 36. The non-transitory machine-readable medium of claim 35, wherein: the application is a first application that executes on a first machine deployed on a first host computer in the cloud; and the set of instructions for providing the generated information to the dRIC comprises a set of instructions for storing the information in a database of the dRIC for later use by a second application that executes on top of the dRIC on a second machine deployed on a second host computer in the cloud.
 37. The non-transitory machine-readable medium of claim 36, wherein the second host computer and second machine are the same as the first host computer and first machine such that the second application that is the consumer of the stored information executes on top of the dRIC on the same machine as the first application.
 38. The non-transitory machine-readable medium of claim 36, wherein: the first and second machines are different machines; and the information is stored in the database of the dRIC by the first application via a shared data layer (SDL) and later retrieved by the different application via the SDL.
 39. The non-transitory machine-readable medium of claim 35, wherein the set of instructions for providing the generated information to the dRIC comprises a set of instructions for providing the generated information to a different application via a messaging infrastructure of the dRIC.
 40. The non-transitory machine-readable medium of claim 35, wherein the consumer of the generated information is the RAN component from which the data is received.
 41. The non-transitory machine-readable medium of claim 40, wherein the RAN component is an Open RAN Distributed Unit (O-DU).
 42. The non-transitory machine-readable medium of claim 35, wherein the application further comprises sets of instructions for, prior to receiving the data: sending a subscription request for the data to the RAN component via the dRIC; and receiving a subscription acknowledgment from the RAN component via the dRIC.
 43. The non-transitory machine-readable medium of claim 42, wherein: the dRIC receives the subscription request from the application through a set of APIs of the dRIC; and the dRIC converts the subscription request received from the application into a subscription request in a format recognized by the RAN component.
 44. The non-transitory machine-readable medium of claim 35, wherein the set of instructions for using the received data to generate information related to at least one user device comprises a set of instructions for applying a machine learning algorithm to the received data. 